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TCL_PLI, a Framework for Reusable, Run Time 
Configurable Test Benches 

RECEIVED 

5 BACKGROUND OF THE INVENTION MAY 0 2 2003 

Technology Center 21 00 

TECHNICAL FIELD 

The invention relates to application specific integrated circuits (ASICs). More 
10 particularly, the invention relates to a framework for reusable, run time 
configurable test benches for the verification of ASIC designs. 

DESCRIPTION OF THE PRIOR ART 

15 As ASIC complexity keeps increasing, the time spent in design and 
maintenance of test benches has grown to become a disproportionately large 
part of the total design effort. In an ASIC verification engine, such as provided 
by Vor il og VERILOG . test benches have become slow to compile and 
cumbersome to maintain. 

20 

The traditional approach to test bench- development and ASIC verification is to 
write a single test bench that contains a number of tasks that exercise 
different aspects of the designs. Team members add new tasks as the 
verification effort continues, and tests are run by calling different sets of tasks 
25 in different order, depending on the functionality being tested. 

One problem with this approach is that the test bench must be recompiled for 
every new simulation. Even though compiled simulators offer features such 
as incremental compilation, in which only the code that changed is 
30 recompiled, this still means that a lot of time is spent compiling test benches. 

Initial efforts to reduce this problem involved using configuration files. In this 

approach, one tries to make the test bench code to be all things to all people. 

Test benches typically contain complicated case statements and if-then-else 

35 sequences. These are controlled by parameters that are read from a text 

configuration file when the simulation is launched. 

1 
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This approach eliminates the need to recompile test benches repeatedly, but 
introduces an even worse problem, i.e. test benches become extremely 
complicated, very difficult to maintain, and very application specific. Often, 
when new functionality is added to a test bench, it has side effects that cause 
5 other tests to break. At the end of the project, one has a test bench that very 
few people understand, and that is so convoluted that there is no possibility of 
reuse. 

It would be advantageous to provide an approach to ASIC verification in 
10 which test benches do not become extremely complicated, very difficult to 
maintain, or very application specific. It would be of additional advantage in 
such approach if, when new functionality is added to a test bench, it does not 
introduce side effects that cause other tests to break. Further, at the end of 
the project, one should have a test bench that anyone can understand, and 
15 that is not so convoluted that there is no possibility of reuse. 

SUMMARY OF THE INVENTION 

A scripting approach to managing the test bench complexity issue is provided. 
20 Partitioning the functionality of a test bench between Vor il og VER1LOG and a 
scripting language allows for a significant reduction in compile times during 
ASIC verification. If done correctly, partitioning also offers great potential for 
re-use of test bench components. 

25 The Tel language was chosen as a basis for implementing a library of PLI 
routines that allow fully customizable interpreters to be instantiated in Vor il og 
VERILOG test benches. This library allows multiple Tel interpreters to be 
instantiated in a Vor il og VERILOG simulation. The Tel interpreters can 
interact with the simulation and cause tasks to be executed in the Vor il og 

30 VERILOG simulation. 

It has been found the TCL_PLI library is extremely valuable in speeding up 
verification efforts on multi-million gate ASICs. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



Figure 1 is a block schematic diagram that illustrates the required interaction 
between the Vori l og VERILOG simulation and a Tel interpreter according to 
5 the invention. 



DETAILED DESCRIPTION OF THE INVENTION 

The invention provides a solution to the problem of providing a reusable test 
10 bench for ASIC design verification by making the configuration files more 
powerful, so that some of the complexity that is coded in Vor il og VERILOG is 
shifted over to something that is evaluated at run time. In essence, a scripting 
language is provided that interacts with the simulation. 

15 With this approach, one can design a simple test bench which contains a 
number of tasks that handle low level interaction with the device under test. If 
these tasks are called from a scripting language, one can develop different 
verification scripts; each test tailored to verifying a specific aspect of the 
design. 

20 

A key difference from the prior art configuration file approach is that the 
intelligence that determines the ordering of events is moved from V e ri l og 
VERILOG to a script file that is interpreted at run time. Different people can 
use the same test bench to test a design in completely different ways. They 
25 have the benefit of significantly reduced need for recompilation, and different 
people on the verification team can be completely insulated from one another. 
Each person can develop their own verification script, and changes to that 
script only affect their own simulations. 

Tel as a choice of scripting language 

30 The initial approach taken was to extend the configuration files that were 
already in use to handle simple conditional and looping constructs, and to 
extend the PLI routines that were in use to process these configuration files to 
become a simple interpreter. 
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It was decided to investigate the feasibility of using Tct as a scripting language 
(see J. Ousterhout, Tel and the Tk Toolkit , p. xvii, Addison-Wesley, (1994)). 
This turned out to be a very good idea. After many attempts to write custom 
5 interpreters for various tools, it was decided to write the ultimate, reusable and 
embeddable interpreter. Tel appeared to have all the characteristics that are 
necessary to implement the invention, i.e. it was already developed, it was 
free, it was easily extendable, and it was easy to embed in an application. 

The obstacle 

10 There was a problem to overcome: 

The Vori l og VERILQG language is extended through function calls. If a user 
needs new functionality, it is implemented in C, and the PLI API is used to 
make it available as a new function that can be called from Vori l og VERILQG . 
15 Tel is also extended through function calls, but new functionality is 
implemented in another compiled language (typically C) and is linked into Tel 
as a new Tel function. 

A system was implemented in which the Vori l og VERILQG simulation starts 
20 up a Tel interpreter and instructs it to run a script. This implied a PLI function 
call. At some point the Tel interpreter encounters a function that is mapped to 
a certain Vori l og VERILQG task. It then must pass control back to Vor il og 
VERILQG so that the task could be executed. This implies that the PLI call 
that invokes the interpreter must return, leaving the problem of how to resume 
25 execution of the Tel script after executing the V e r ilo g VERILQG task. 

In addition to extending the functionality of configuration files through the use 
of a scripting language, it was necessary to invent a system through which 
one could pass control between Vori l og VERILOG and Tel, through function 
30 calls on either side. In this way, the Vori l og VERILOG code controls when Tel 
interpreters are invoked, but the Tel interpreters cause V e r il og VERILQG 
tasks to be executed (implying that a PLI call needs to return), while retaining 
the state of the Tel interpreter so 4that it could resume execution of the 
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Tel script after the Vorilog VERILQG task completed. 
The solution 

The preferred embodiment of the invention solves this problem by 
5 implementing a simple client-server model, in which the Tel server runs on a 
separate thread from the Vori l og VERILQG simulation. Figure 1 is a block 
schematic diagram that illustrates the required interaction between the Vor il og 
VERILQG simulation 10 and a Tel interpreter 20. Synchronization between 
the Vor il og VERILQG simulation and the Tel server is performed via a set of 

10 semaphores. This allows control to be passed freely between V e r il og 
VERILQG and Tel. The Vori l og VERILOG code determines when Tel 
interpreters are invoked and Tel interpreters can randomly cause Vor il og 
VERILOG tasks to be executed. Thus, a PLI function call executes a Td script 
(100), a C function call executes a Vor il og VERILOG task (110), and a PLI 

15 function call resumes script execution (120). 

The TCL_PLI library allows any number of Tel interpreters to be instantiated in 
a V e r il og VERILQG simulation. Every interpreter is completely customizable. 
PLI functions initialize interpreters and define new Tel functions that are 
20 mapped to Vori l og VERILQG tasks. PLI functions also start running scripts on 
the Tel interpreters and pass control between Vor il og VERILOG and Tel. 

The Vor il og VERILOG tasks have access to arguments passed to the Tel 
functions that invoked them, allowing information to be passed from Tel to 
25 Vor il og. VERILOG. The Vor il og VERILOG tasks also have the ability to 
control the return values of their Tel counterparts, allowing information to be 
passed from Vor il og VERILOG to Tel. PLI routines are also provided that 
allow direct sharing of information between Tel and Vor il og VERILOG . as well 
as between different Tel interpreters. 

30 Interaction between V e r il og VERILOG and Tel 



At the core of the TCL_PLI library are four PLI functions: $tcllnit, 

5 
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$tclExec, $tclGetArgs, and $tclClose. 

• $tctlnit creates and initializes a new Tel interpreter. It defines the new Tel 
functions that are used to invoke Vor il og VERILOG tasks, maps them to 

5 specific tasks, and defines how many arguments they take. 

• $tclExec passes control from Vori l og VERILOG to the Tel server. It 
launches a new script or resumes execution of a script that was stalled 
when the interpreter encountered a function that was mapped to a Vor il og 

10 VERILOG task. $tclExec returns under one of three conditions: when an 
error occurs, when the script ends, or when a function is encountered that 
is mapped to a Vori l og VERILOG task. 

• StclGetArgs accesses the argument values that were passed to an 
15 extended Tel function. 

• $tclClose destroys a Tel interpreter and frees the resources with which it is 
associated. 

20 The following code segment (Table A) shows how an interpreter is created 
and initialized in V e r il og VERILOG . The interpreter has three extended Tel 
commands (b_write, b_read and b_wait_irq) that are mapped to Vori l og 
VERILOG tasks. These commands allow scripts running on the interpreter to 
write data on a bus, read data from a bus, or wait for an interrupt to occur on 

25 the bus. 

Table A 



1 parameter 
30 2 BUS_WRITE = 1, 

3 BUS_READ = 2, 

4 BUS_WAIT_IRQ = 3 ; 

5 initial 6 begin: processor_model 

6 
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7 integer tcl_handle, 

8 tcl_command, tcl_return_value ; 

9 // Initialize interpreter that 
10 // knows about the three 

5 11 // extended Tel commands: 

12 tcl_handle = $tcllnit ( 

13 "processor", tcl_coinmand, 

14 tcl_return_value, 

15 "b_write" , BUS_WRITE, 2, 
10 16 " b_r ead " , BUS_READ , 1 , 

17 "b_wait_irq" , BUS_WAIT_IRQ, 0 

18 ) ; 

19 if (tcl_handle == 0) 
2 0 begin 

15 21 $display ("Init error."); 

22 $finish; 

23 end 

On lines 1 to 4, three integer parameters are defined that represent the three 
extended Tel commands in Vori l og VERILOG . Lines 7 and 8 define three 

20 variables that are used to communicate between Vor i log VERILOG and Tel. 
tcl_handle stores the handle of this interpreter. Each interpreter has a unique 
handle. It is returned by the $tcllnit PLI function and is used by all other 
TCL_PLI functions to identify the interpreter that is being addressed. 
tcl_command is used by TCL_PLI to indicate to Vor i log VERILOG which 

25 extended Tel function had been encountered while executing the script. It 
also indicates the completion status of the Tel script when execution of the 
script ends. tcl_return_value is used by Vori l og VERILOG to communicate 
the return values of tasks back to the calling Tel functions. 



30 On lines 12 to 18, the call to $tcllnit initializes the interpreter. It identifies the 
variables tcl_command and tcl_retum_value to TCL_PLI. It also defines the 
extended Tel functions b_write, b_read and b_wait_irq. $tcllnit associates an 
integer value with each extended Tel function and stores the number of 
arguments that each extended Tel function should expect. $tcllnit can take a 

7 



^^^ERSION OF AMENDED SPECIFICATION 

WITH MARKINGS TO SHOW CHANGES MADE 



variable number of arguments to allow definition of any number of extended 
Tel functions. 

The return value of $tcllnit contains the handle of the newly created Tel 
5 interpreter. If the value is zero, this is an indication that an error occurred 
while creating and initializing the interpreter. The test on line 19 confirms that 
the call to $tcllnit completed successfully. 

The following code segment (Table B) indicates how a script is executed on a 
10 Tel interpreter and how control is passed between Vori l og VERILQG and Tel. 

Table B 



24 while ($tclExec { tcl_handle , 

15 25 icxomplc. tell) ) 2 6 "example . tel " ) ) 

26 begin 

27 tcl_return_value = 0; 

28 case (tcl_command) 

29 BUS_WRITE: 

20 30 bus_write (tcl_handle) ; 

3 1 BUS_READ : 

32 bus_read (tcl_handle, 

33 tcl_return_value) ; 
3 4 BUS_WAIT_IRQ : 

25 3 5 bu s_wa i t_i r q ; 

3 6 endcase 

37 end // while 

3 8 if ( tcl_command != 0) 

3 9 begin 

30 4 0 $display ( 

41 "Error in Tel script!"); 

42 $finish; 

43 end 

44 $tclClose (tcl_handle) ; 
35 45 end // processor_model 
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When $tclExec is encountered the first time (line 24), the Tel server is idle. 
This is an indication that it should start executing the script 
loxamplo.toi r example.tcl" . As mentioned earlier, $tclExec returns under one 
of three conditions: if an error occurs, if the script ends, or if an extended Tel 
5 function is encountered. A non-zero return value indicates that an extended 
Tel function had been encountered. A return value of 0 indicates that the 
script has ended or that an error occurred. In the case where an extended Tel 
function is encountered, the Tel interpreter stalls until the next call to $tclExec 
informs it that the Vorilog VERILOG task has been executed. 

10 

The while loop (lines 24 to 37) continues looping as long as the return value of 
$tclExec remains positive. This means that the simulator continues executing 
Vor il og VERILOG tasks as they are encountered in the Tel script that is being 
executed. If $tclExec is called when the Tel server is not idle, it assumes that 
15 execution of the current script should continue. $tclExec checks that the 
script name passed to it matches the name of the script being executed and 
returns an error value if this is not the case. 

Not all Vor il og VERILOG tasks have meaningful return values. Therefore, 
20 tcl_return_value is initialized to zero to ensure that an undefined value is not 
eventually returned to the Tel interpreter (line 27). 

Whenever $tclExec returns a non-zero value, the tcl_command variable 
contains the integer value corresponding to the extended Tel function that was 
25 encountered in the script. The case statement on line 28 calls the V e ri l og 
VERILOG task associated with this Tel function. 

Once the Vor il og VERILOG task completes, the while loop continues with 
another call to $tclExec. $tclExec again returns when it encounters an 
30 extended Tel command, reaches the end of the script, or encounters an error. 
The result is that the while loop causes the whole Tel script to be executed, 
and Vor il og VERILOG tasks are called in the order determined by the 
execution of the Tel script. 

9 
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When the while loop terminates, it is appropriate to check that no error 
occurred (line 38). When $tclExec returns zero (causing the while loop to 
terminate), the tcl_command variable contains an exit code indicating either 
5 normal termination (end of script reached) or abnormal termination (due to an 
error in the script). 

At this point, the Tel interpreter can be deleted if it is no longer required (line 
44). It should be noted that the same interpreter can be used repeatedly. 
io Scripts can also be run on the interpreter from different points in the Vor il og 
VERILOG code. TCL_PLI generates an error if an attempt is made to run 
multiple scripts on one interpreter simultaneously. Interpreter state 
information (such as variable values and procedure definitions) is preserved 
until the interpreter is destroyed through a call to $tclClose. 

15 

The following code segment (Table C) shows the definition of the Vorilog 
VERILOG tasks that are called under control of the Tel interpreter. 

Table C 

20 

49 task bus_write; 

50 input [31:0] tcl_handle; 

51 integer address, data; 

52 begin 

25 53 $tclGetArgs (tcl_handle, 

54 address , " i " , 

55 data, " i" 

56 ) ; 

57 // Simulate the write cycle 
30 5 8 // on the bus 

59 end 
60 

61 task bus_read; 

62 input [31:0] tcl_handle; 

35 63 output [31:0] data; 64 integer address; 
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65 begin 

66 $tclGetArgs ( tcl_handle , 

67 address, "i" 

68 ) ; 

5 69 // Simulate the read cycle 

70 //on the bus 

71 data = data_read_f rom_bus ; 

72 end 
73 

10 74 task bus_wait_irq; 

75 begin 

76 @ (bus_irq) ; 

77 end 



15 A Vor il og VERILOG task can gain access to the arguments of the Tel function 
by which it is invoked. For this purpose, the handle of the interpreter is 
passed to these tasks (line 50). A call to StclGetArgs is used to transfer this 
information from Tel to Vor il og VERILOG (line 53). StclGetArgs can handle 
integer or string arguments, and performs the appropriate conversions. 

20 

The bus_read Vor il og VERILOG task illustrates how the return value of a Tel 
function is set up in the Vor il og VERILOG task (lines 71 and 33). TCL_PLI 
assumes that the return value is an integer. The bus_wait_irq task illustrates 
a simple case where the Tel interpreter can be stalled while waiting for an 
25 event in the simulation (line 76). 

The following (Table D) is a sample Tel script that can be run in the Vori l og 
VERILOG example shown above. It illustrates how the execution order of the 
Vor il og VERILOG tasks are completely controlled from Tel. In essence, the 
30 Tel script is in complete control of the simulation in the same way that 
software controls the hardware on which it is run. 
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Table D 



1 # Write to a register, wait 

5 2 # for an interrupt and read back 

3 # a cause: 

4 puts " $::vname @ $::vtime: \ 

5 Writing Oxaa to address 0x05:" 

6 b_write 0x05 Oxaa 

10 7 puts "$:: vname @ $::vtime: \ 

8 Waiting for interrupt- - . " 

9 b_wait_irq 

10 puts " $::vname @ $::vtime: \ 

11 Interrupt received" 

15 12 puts [format "Address 0x05 now \ 

13 contains %x" [b_read 0x05]] 
14 

15 # Write to another register, 

16 # then poll until bit 1 changes: 
20 17 puts "$: :vname @ $::vtime: \ 

18 Writing Oxff to address 0x0a:" 

19 b_write 0x0a Oxff 

20 set bit_l 0x0 

21 while {$bit_l} { 

25 22 # Read 0x0a and check the LSB: 

23 set bit_l \ 

24 [expr [b_read 0x0a] && 0x01] 

25 puts "$::vname @ $::vtime: \ 

26 Bit 1 value is $bit_l" 
30 2 7 } 

28 puts "$::vname @ $::vtime: \ 

29 Value changed!" 



The variables vname and vtime are defined by the TCL_PLI library, vname 
35 contains the name of the interpreter (passed as the very first argument to 
$tcllnit). It is useful to determine the source of a message, vtime 
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cpntains the current simulation time, which is very useful for tracing simulator 
messages back into waveforms. 

Behind the scenes 

As mentioned previously, the Tel interpreter is run on a separate thread from 
5 the V e ri l og VERILOG simulation. A call to $tcllnit causes a secondary thread 
to be created, on which the Tel server runs. The Tel server creates and 
initializes a new Tel interpreter, and then enters a loop in which it waits for and 
executes commands received from the PLI functions. 



10 The following C code segment (Table E) is a simplified version of the 
command loop in the Tel server. 



Table E 



15 



20 



25 



30 



1 /* Wait for and service requests 

2 to run scripts */ 

3 runServer = 1 ; 

4 while (runServer) 

5 { 

6 /* Pass control to the Vorilog VERILOG 

7 thread */ 

8 sem_post (&t->t2v) ; 

9 /* Wait for an instruction from 

10 the Verilog VERILOG thread */ 

11 sem_wai t (&t->v2t) ; 

12 switch { t->serverCommand) 

13 { 

14 case TC_RUNSCRIPT : 

15 t->serverStatus = 

16 tclServer_runScript (t) ; 

17 break; 

18 case TC_CLOSE: 

19 runServer =0; 20 



35 



TS_DONE ; 



1321 



t->server Status 
break ; 



Version of amended specific^ion 
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, 22 case TC_ADDCOMMAND : 

23 /* Add new commands to 

24 interpreter */ 

25 break; 

5 26 case TC_LINKVARS : 

27 /* Link with Vcrilog2S VERILOG 

28 variables */ 

29 break; 

3 0 case TC_SHAREVARS : 

10 31 /* Link with variables from 

32 other interp */ 

33 } 

34 } 



15 Once the Tel server is initialized, it enters the command loop and immediately 
posts the t2v semaphore to the PLI to indicate that it is ready to accept a 
command. It then waits for the v2t semaphore. Upon receipt of the v2t 
semaphore, it examines the serverCommand member of its defining structure 
to determine what command was issued and executes the command. When 

20 the command is completed, the loop starts again. 



On the Vor i log VERILOG thread, a PLI function sends a command to the Tel 
server by setting up the serverCommand member of the corvor i o server's 
defining structure and then posts the v2t semaphore. The PLI function then 
25 waits for the t2v semaphore as an indicator that control is being passed back 
to Vori l og VERILOG . 



The following sequence takes place if the Tel script in the previous example is 
executed: 

30 

• When $tclExec is called from the Vori l og VERILOG simulation the first time 
(Tel server is idle), it instructs the Tel server to start executing the script, 
and then waits for the t2v semaphore. The Tel server executes lines 1 
through 5 of the script. When it reaches line 6, which contains the 
35 extended command b_write, it , 4 calls the function 
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, tclServer_verilogCall. This function is called for all extended commands 
that are mapped to Vori l og VERILQG tasks. tclServer_veri log Call saves 
the relevant information in its defining structure, posts the t2v semaphore, 
and then waits for the v2t semaphore. 

• When $tclExec receives the t2v semaphore, it synchronizes linked 
variables and returns to Vorilog VERILQG . This allows the simulator to 
enter the while loop in which it executes the tasks associated with 
extended Tel functions (lines 24 to 37 of the Vorilog VERILQG example). 
When the task associated with b_write completes, $tclExec is again called. 
This time the Tel server is not idle, so $tclExec assumes that execution of 
the script should resume. It synchronizes linked variables, posts the v2t 
semaphore, and waits for the t2v semaphore. 

• tclServer_verilogCall receives the v2t semaphore and returns, allowing 
execution of the Tel script to continue. This process repeats itself until the 
script completes. When this happens, the Tel server indicates this to the 
PLI when posting the t2v semaphore. This time, when $tclExec returns, 
the Ver i log VERILQG while loop terminates. 

The following C code segment (Table F) shows a simplified version of 
tclServer_verilogCall, the function that is called by the Tel interpreter when it 
encounters an extended command. 

Table F 



1 int tclServer_verilogCall (...) 

2 { 

3 /* Store the command value for 

4 the Vorilog VERILQG thread */ 

5 t->commandValue = 

6 command->value; 

7 /* Store the argument array 

8 and count in the 15interpreter 
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9 struct to make it accessible 

10 to tclGetArgs: */ 

11 t->argc = argc ; 

12 t->argv = argv; 

5 13 /* Semaphore vcrilog VERILOG */ 

14 sem_post (&t->t2v) ; 

15 /* At this point control has 

16 been passed back to Vcrilog, 17 VERILOG, 

17 where the functionality is 
10 18 being simulated. Once done, 

19 the main thread will 

20 semaphore this thread to 

21 continue- */ 

22 /* Wait for semaphore from 
15 23 vcrilog VERILOG */ 

24 sem_wait (&t->v2t) ; 

25 /* Set up the return value */ 

26 sprintf (message, "%d", 

27 t->retVal) ; 

20 28 Tcl_SetResult (t->interp / 

29 message, TCL_VOLATILE ) ; 
3 0 return TCL_OK; 
31 } 

It is important to note that, even though TCL_PLI is multi-threaded, and that 
25 every interpreter is run on a dedicated thread, the essential single threaded 
nature of Vor il og VERILOG simulations is maintained. Only one call to 
$tclExec can be reached in the Vor i log VERILOG simulation at any given 
time. The Vor il og VERILOG simulation stalls until this call returns, which 
occurs when the Tel interpreter calls tclServer_verilogCall or when the script 
30 completes. tclServer_verilogCall, on its part, only returns when the next call 
to $tclExec is encountered in the Vori l og VERILOG simulation. This means 
that, even though many Tel scripts may be in the process of execution at any 
given moment in time, only one of them or the Vor i log VERILOG code itself is 
running at that moment. All event scheduling and execution order is still 
35 under the control of the simulator. 

16 
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It should also be noted that the Tel server executes scripts in zero simulation 
time. Simulation time does not advance for the duration of a call to $tclExec. 
Simulation time advances normally while the Vor i log VERILOG tasks invoked 
from Tel are executed 

5 The TCL_PLI library 

The following discussion provides a brief overview of the PLI functions 
available in the EFI_PLI library. The Stcllnit, $tclClose, $tclExec and 
$tclGetArgs PLI functions have already been discussed in detail and are not 
listed again in this section. 

10 StclLinkVariables and $tclShareVariables 

StclLinkVariables allows direct sharing of variables between Ver il og VERILOG 
and Tel. It links a list of Vor il og VERILOG variables with a list of Tel variables. 
The TCL_PLI library then automatically keeps these variables synchronized 2s. 
until the interpreter is deleted. StclLinkVariables has support for integer and T 
15 string variables, and can mark variables as read-only in the Tel interpreter, 
meaning that they can be modified in Vori l og VERILOG . but not in Tel. 



StclShareVariables allows direct sharing of variables between two different^Tcl 
interpreters, without any connection to Vor il og VERILOG . After a call to 
20 StclShareVariables, the list of Tel variables in both interpreters are 
automatically synchronized by the TCL_PLI library, until one of the 
interpreters is deleted. 

StclSetMCD and StclAddMCD 

StclSetMCD and StclAddMCD allow the Tel interpreter access to multi-channel 
25 descriptors in the Vor i log VERILOG simulation. This allows the user to 
redirect messages from the Tel interpreter into log files that also record 
messages directly from the simulation, which is critical for preserving the order 
in which messages were generated. Any Vor il og VERILOG multi-channel 
descriptor can be associated with a Tel interpreter. If an interpreter has an 
30 associated MCD, its built-in puts .-command is modified, causing all 
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output to stdout to be redirected to the multi-channel descriptor. This makes it 
very easy to open a log file and set up an MCD that causes all messages from 
the simulation (both from Vori l og VERILOG and Tel) to be printed to stdout, as 
well as being recorded in a log file. 

5 StclSetErrorReg 

StclSetErrorReg allows the user to identify one register in the Vor i log 
VERILOG simulation that is linked to any error occurring in any interpreter or 
in TCL_PLI. If any error occurs, the value of this register is changed, allowing 
the simulation to react to the error immediately. 

10 StclWarnOnX 

As with any software language, Tel has no concept of X or Z values. The 
default behavior of TCL_PLI causes execution of the Tel script to be 
terminated under any of the following conditions: 



15 If the return value of an extended Tel function is X or Z, or if any linked 
variable is X or Z at a point where it is evaluated in the script. 



For purposes of the preferred embodiment of the invention, this is correct and 
desirable behavior. In the presently preferred embodiment of the invention, X 

20 and Z values should never propagate into the software domain because 
software can not handle these values. However, some users of TCL_PLI do 
not share this opinion, and hence the existence of StclWarnOnX. Calling 
StclWarnOnX causes TCL_PLI to print a warning message under any of the 
previously described conditions. Execution of the script continues. If the 

25 variable in question is an integer, its Tel value is considered to be zero. If it is 
a string, its Tel value is iZz f'Zz" . 



Note that only a warning message is generated. In a simulation that prints 
many messages, this message can easily scroll off the screen before being 
30 noticed. The misinterpretation of the V e r il og VERILOG value in Tel can 
ultimately cause all sorts of ^strange behavior and may cause 
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problems the user who decides to use StclWarnOnX. 
Example: PCI_TCL 

The preferred embodiment of the invention includes a module that instantiates 
Synopsys LMC source models for a PCI master and a PCI slave together with 

5 two Tel interpreters. The tasks supplied with the PCI models are mapped to 
extended Tel functions, allowing one to execute Tel scripts that interact with 
other devices on a PCI bus. The Vori l og VERILOG code causes one of the Tel 
interpreters to start executing a script when it senses an interrupt on the PCI 
bus. This allows easy modeling of interrupt service routines written in Tel. 

10 Execution of a Tel script can be linked to an interrupt by waiting in the Vori l og 
VERILOG code for the interrupt to occur before entering the while loop calling 
$tclExec. 



The two interpreters in the PCI master have to compete for access to the bus. >r 

15 This is accomplished through a simple gating mechanism that checks whether c 

the bus is busy before calling a task that starts a transaction on the bus. If the t: 
bus is busy, it waits for the current transaction to complete before starting the 
new one. This arrangement models actual software behavior very well, where 

several processes running on a CPU have to compete for access to the PCI :Z 
20 bus, with no guarantee on the order in which accesses takes place. 

The PCLTCL module allows both interpreters to load data files directly into 
the LMC slave memory (in zero simulation time). Data can also be dumped 
from the slave memory to a file. Both interpreters can execute memory or I/O 

25 transactions on the bus. Two extended Tel functions are used for bursting 
commands: the one executes the address phase of a burst while repeated 
calls to the other executes one data cycle per call. An encapsulating Tel 
procedure takes an address, byte count, and byte array and performs a 
corresponding burst read or write on the PCI bus by appropriately calling the 

30 underlying extended Tel functions. 
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The PCL.TCL module allows extensive testing of any PCI based device 
without writing a single line of Vor il og VER1LOG code for the test bench. The 
preferred embodiment of the invention also comprises a library of Tel 
procedures that simplifies tasks such as configuration of PCI devices. 

5 TCL_PLI in practice 

The TCL_PLI library has been used to verify a 600k gate design and is 
currently being used on two designs, both of which are larger than one million 
gates. All of these designs are PCI based ASICs. Using the PCI_TCL 
module has made it possible to write elaborate scripts that interact with the 
10 device under test in very much the same way as software would interact with 
the real hardware. 



Tel interpreters were also used in modules that interact with other ports on -the 
device under test. In each case," Vori l og VERILOG tasks were written that 
15 know how to interact with a port at a low level. The higher level behavior of 
the test module is then controlled by a Tel script. This allows one to change 
the behavior of test modules radically by running differing Tel scripts on them. 



In the presently preferred test benches, there typically is a master Tel 
20 interpreter that controls all test modules that interact with the device under 
test. It determines which Tel scripts are executed when and on what module. 
This approach provides centralized control over an extremely configurable test 
bench. 

Pitfalls 

25 There are a number of pitfalls to watch out for when using the TCL_PLI 
library. Most important are some issues related to the simulator. The 
presently preferred embodiment of the invention comprises use of the 
TCL_PLI library with Svnopsvs f Synopsvs* VCS simulator. With VCS version 
4.0.3 it was necessary to compile through C code. VCS allows compilation 

30 through C, assembler, or directly to object code. Compilation through C is the 
slowest, but Synopsys advises to ?n compile through C if using multi- 
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threaded PLI. Not doing this causes immediate core dumps, even when the 
TCL_PLI library is linked in, but not used. The presently preferred 
embodiment of the invention comprises VCS version 5.0.1 . This version does 
allow one to compile directly to assembler or object code. It should also be 
mentioned that, other than the penalty of slower compile times, VCS 4.0.3 
works perfectly well with TCL_PLL 

Following is a list of compile time options for VCS that are needed when using 
the TCL_PLI library: 

• -Xstrict: Prevents VCS from using resources that are used by the multi- 
threading library. 

• -Ipthread -Rlposix4: Link with the Posix threading support libraries. 

TCL_PLI has also been used with Cadence Vor il og VERILOG -XL version 2.5. £ 



One of the most common problems encountered by first-time users, is that 
they forget to assign a default value for the return value register in the while 

20 loop that executes the Tel script. TCL_PLI has no way to distinguish whether 
a return value is used, and always complains if a return value is X or Z. 
Therefore, a default value should always be assigned. A problem that was 
anticipated, but that is not encountered frequently, is with Tel bugs in long 
running simulations. Because Tel is an interpreted language, a syntax error is 

25 only detected when the interpreter encounters the statement that contains the 
error. There were concerns that a simulation could start off that would run 
very long, only to have it die near the end due to a bug in the Tel script. The 
way that this problem is presently managed is to develop scripts 
incrementally, thereby ensuring that long-running simulations are performed 

30 with proven Tel code. 
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(Conclusion 



The preferred embodiment of the invention significantly reduces time spent 
recompiling test benches. Test benches are a simpler, and consist of 
modular, reusable modules that are easy to maintain. New tests are 
5 implemented in new, separate scripts, eliminating the problem where addition 
of new tests causes existing tests to break. 

The Tel scripts themselves are often reusable. When module level testing is 
performed, functionality between Tel and V e r il og VERILOG is partitioned 

10 such that the Tel scripts are reusable in system level testing. As an example, 
a Tel interpreter interacting with a module uses extended Tel functions that 
take the same arguments and return values as matching functions in the 
PCI_TCL module, even though it is not interacting with a PCI bus. This way, 
the scripts that are developed for testing the module can be rerun without 

15 modification in system level tests. 

In one use of the invention, it was possible to reuse a complicated Tel script 
written for a project that was cancelled. The module was initially written to 
test a memory controller by performing random reads and writes and 
20 automatically verifying data integrity. When it was later necessary to design 
logic that had to access system memory through a PCI bus, the script was 
reused without modification. 

Another embodiment of the invention allows the porting of Tel scripts to real 
25 hardware. This enables a verification suite to run on ASICs when they return 
from the foundry. 

Although the invention is described herein with reference to the preferred 
embodiment, one skilled in the art will readily appreciate that other 
30 applications may be substituted for those set forth herein without departing 
from the spirit and scope of the present invention. Accordingly, the invention 
should only be limited by the Claims included below. 
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